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TECHNICAL FIELD: 



These teachings relate generally to wireless communications systems and, more specifically, to 
procedures for determining a location or a position of a mobile station (MS) within the wireless 
network (NW). 
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The following 
3G 

A/Gb mode 

15 

BSC 
BTS 
CN 
CRS 
20 CS 
DL 
EDGE 
E-OTD 
GERAN 
25 GGSN 

GMLC 

GPS 

GRA 

GSM 
30 GTP 

HO 

IMSI 

IP 



abbreviations are herewith defined. 
Third Generation (cellular system) 

Mode of operation of MS when connected to the core network via GERAN and 

the A and/or Gb interfaces 

Base Station Controller 

Base Transceiver Station 

Core Network 

Cell Re-Selection 

Circuit Switched 

Down Link (to the MS) 

Enhanced Data rate for Global Evolution 

Enhanced-Observed Time Difference 

GSM/EDGE Radio Access Network 

Gateway GPRS Support Node 

Gateway Mobile Location Center 

Global Positioning System 

GERAN Registration Area 

Global System for Mobile Communications 

GPRS Tunneling Protocol 

Handover 

hitemational Mobile Subscriber Identity 
Internet Protocol 
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lu mode 

lur 
lur-g 
5 LCS 
ME 
MM 
MS 
MSG 
10 NAS 
PDCP 
PDP 
PDU 
PS 
15 QoS 
RAB 
RAN 
RANAP 
"RNC 
20 RNTI 
RR 
RRC 
RRLP 
SGSN 
25 SMLC 
SRNS 
UE 
UL 

UMTS 
30 URA 
UTRAN 
VMSC 



Mode of operation of MS when connected to the core network via GERAN or 

UTRAN and the lu interface 

A logical interface between two RNC 

A logical interface between two BSCs 

Location Services 

Mobile Equipment 

MobiUty Management 

Mobile Station 

Mobile Switching Center 

Non-Access Stratum 

Packet Data Convergence Protocol 

Packet Data Protocol 

Packet Data Unit 

Packet Switched 

Quality of Service 

Radio Access Bearer 

Radio Access Network 

Radio Access Network AppUcation Part 

Radio Network Controller 

Radio Network Temporary Identity 

Radio Resources 

Radio Resource Control 

Radio Resovirce Location Procedure 

Serving GPRS Support Node 

Serving Mobile Location Center 

Serving RNS 

User Equipment 

Uplink (from the MS) 

Universal Mobile Telecommunications System 
UTRAN Registration Area 
Universal Terrestrial Radio Access Network 
Visited MSG 
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Reference can also be madeto3GPPTR21.905,V4A0(2001-10).TWrdGenerationPartnership 
Project; Technical Specification Group Services and System Aspects; Vocabulary for 3GPP 
Specifications (Release 4). 

5 Over the period of a decade the GSM standard has evolved firom a basic voice service to a wide 
variety of speech and data services, hi the 3GPP Release 5 the fimctional split between the 
GSM/EDGE Radio Access Network (GERAN) and the core network (CN) will be aligned with 
the fimctional split between UTRAN and the CN, thereby enabling GERAN to connect to the 
same 3G core network and to provide the same set of services as UTRAN. This fimctionality 
10 split impUes a new architecture for GERAN and significant modifications to the GERAN radio 
1^ protocols. 

s 

B 

1 Several new interfaces such as lu and lur-g are defined for the GERAN architecture. The lu 

i interface is common between UTRAN and GERAN. An lu-ps and lu-cs interface is being 

I 15 considered, where lu-ps is the interfk:e targeted for the packet switched (PS) domam. and lu-cs 

- is the interface targeted towards the circuit switched (CS) domain. Both of these interfaces will 
be supported by the GERAN specifications. The lur-g is the interface between two GERANs. 
and supports signaling information between them (note that the lur-g is currently planned to 
support only the control plane procedures of lur). 
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A Mobile Station (MS) can be attached to the core network through either the lu-cs or lu-ps, or 
through both the lu-cs and lu-ps interfaces. The MS can also be attached to the CN through the 
legacy interfaces A and Gb. As a result, the GERAN Radio Resource Control (RRC) protocol 
is based on both the GSM Radio Resource (RR) and the UTRAN RRC specifications. The MS 
25 can operate in either the A/Gb mode or the lu mode. The A/Gb mode is defined for the MS when 
comiected to a GERAN with no lu interface towards the CN. The lu mode is defined for the MS 
when connected to a GERAN with lu interfaces towards the CN. 

UMTS has a standardized relocation procedure that is expected will be used as well in the 
30 GERAN lu mode. Figs. 1 and 2 illustrate the relocation procedure, and can be found as well in 
the standard 3G TS 23.060, V4.2.0 (2001-10), Third Generation Parmership Project; Technical 
Specification Gix5up Services and System Aspects; General Packet Radio Service (GPRS); 



Service Description; Stage 2 (Release 4). More specifically. Fig. 2 shows the operation of the 
currently specified Combined Hard Handover and SRNS Relocation procedure for the PS 
domain. The illustrated sequence is valid for both intra-SGSN SRNS relocation and for inter- 
SGSN and SRNS relocation. Fig. 3 shows the operation of a Combined Cell /URA Update and 
5 SRNS Relocation procedure for the PS domain. This sequence is valid for both intra-SGSN 
SRNS relocation and for inter-SGSN SRNS relocation. The Cell Update and Relocation 
procedures have been accepted by standardization committees to be adopted from UTRAN to 
GERAN lu mode. 

10 According to current GSM specifications (Release 1998 (R98) and Release 1999 (R99), GSM 
03.71), the E-OTD and GPS MS positioning procedures are terminated in the case of handover, 
upon the occurrence of some other RR management procedure. More specifically, what is 
currently specified is that: 



Q 

.R or 



15 The BSC shall terminate any network or MS positioning procedure or any 

transfer of RRLP assistance data already in progress if inter-BSC or inter-MSC 
Q handover is needed and is not precluded by the particular location procedure and 

its current state. 

U 20 The BSC shall terminate any network or MS positioning procedure or any 

Q transfer of RRLP assistance data already in progress if an intra-BSC handover or 

fiJ other intra-BSC RR management procedure is needed and is not precluded by the 

particular location procedure and its current state. 

25 As may be appreciated, the current approach results in GPS and E-OTD positioning procedures 
being terminated in many cases due to HO or some other RR procedure, requiring the VMSC 
(or the GMLC) to restart the MS positioning procedure. This results in additional delays, as well 
as in an increased MS power consumption, and the in some cases the entire positioning operation 
may fail within the time specified by an appUcation. 

30 

SUMMARY OF THE PREFERRED EMBODIMENTS 

The foregoing and other problems are overcome, and other advantages are realized, in 
accordance with the presently preferred embodiments of these teachings. 

35 

These teachings pertain to Assisted GPS, E-OTD and other suitable location methods and 



systems and provide a technique to avoid undesired termination of a LCS procedure due to some 
RR procedure (e.g., HO or CRS). The LCS process and the supplying of its associated 
parameters are moved when required from a current serving BSC/RNC/SMLC and MSC/SGSN 
to a new serving entity with a relocation procedure. These teachings are applicable, for example, 
5 to GERAN lu mode standards as well as to UTRAN standards, and may be applied as well to 
the GERAN A/Gb mode, while possibly requiring a new interface between BSCs (comparable 
to the lur-g interface in the lu mode) when operating in the A/Gb mode. 

A method is disclosed for operating a mobile station in cooperation with a network operator, as 
10 is a system including the mobile station and the network operator. The method operates, upon 
Q an occurrence of a RR procedure, including HO and CRS, that affects the mobile station, to 
Q determine if a location procedure is ongoing in the mobile station and, if it is, to complete the 
S location procedure and to report the measurement results (which may be a failure indication) in 
S a message from the mobile station to a target radio network controller. The location procedure 
S 15 can be, in accordance with an embodiment of this invention, a LCS procedure that is executed 
O during a Combined Hard Handover and SRNS Relocation procedure, for both the PS and CS 
n domains, and applies to both intra-SGSN/MSC SRNS relocation and inter-SGSN/MSC and 
H SRNS relocation. The location procedure can also be, in accordance with another embodiment 
of this invention, a LCS procedure that is executed during a Combined Cell/URA Update and 
20 SRNS Relocation procedure for the PS domain, and also apphes to both intra-SGSN SRNS 
relocation and for inter-SGSN SRNS relocation 

For the LCS procedure, the method fiuther sends LCS parameters from a source RNC/BSC to 
the target RNC/BSC . The LCS parameters in this case are sent in a Source RNC to Target RNC 
25 Transparent Container in a Relocation Required message (note should be made that the name 
of this container is UTRAN specific, and that it may be referred to differently in, for example, 
GERAN). LCS parameters may also be sent from the source BSC/RNC to the target BSC/RNC 
in a Relocation Commit (SRNS Contexts) message or, if no Iur(-g) is available, in a Forward 
SRNS Context message. Note in this case that the reference to lur-g is GERAN specific, but 
30 should not be viewed as being a limitation upon the practice of this invention. 



The LCS parameters can include at least one of (i) a requested location accuracy; (ii) a requested 



location response time; (iii) details pertaining to a currently ongoing location process; and (iv) 
a GMLC address. 



The measurement results message may be sent by the mobile station before or after sending a 
5 GERAN/UTRAN Mobility Information Confirm message from the mobile station to the target 
BSC/RNC. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 The foregoing and other aspects of these teachings are made more evident in the following 
Detailed Description of the Preferred Embodiments, when read in conjunction with the attached 
Drawing Figures, wherein: 

Fig. I is a block diagram of a wireless communications system that is suitable for practicing 
15 these teachings; 

Fig. 2 illustrates the operation of a conventional Combined Hard Handover and SRNS 
Relocation procedure for the PS domain, where the illustrated sequence is valid for both intra- 
SGSN SRNS relocation and for inter-SGSN and SRNS relocation; 

20 

Fig. 3 illustrates the operation of a conventional Combined CellAJRA Update and SRNS 
Relocation procedure for the PS domain, where the illustrated sequence is valid for both intra- 
SGSN SRNS relocation and for inter-SGSN SRNS relocation; 

25 Fig. 4 illustrates the operation of the relocation procedure with LCS data for the case of Cell 
Reselection (PS domain) in accordance with the teachings of this invention; and 

Fig. 5 is a logic flow diagram that illustrates an LCS Relocation in an IP RAN architecture in 
accordance with a further aspect of these teachings. 

30 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring first to Fig. 1, there is illustrated a simplified block diagram of an embodiment of a 
wireless communications system 5 that is suitable for practicing this invention. The wireless 
5 communications system 5 includes at least one mobile station (MS) 100, also referred to herein 
as User Equipment (UE). Fig. 1 also shows an exemplary network operator having, for example, 
a Serving GPRS Support Node (SGSN) 30 for connecting to a telecommunications network, 
such as aPublic Packet Data Network or PDN, at least one base station controller (BSC) 40, and 
a plurahty of base transceiver stations (BTS) 50 that transmit in a forward or downlink direction 
10 both physical and logical channels to the mobile station 100 in accordance with a predetermined 
^ air interface standard. A reverse or uplink communication path also exists fi-om the mobile 
5 station 1 00 to the network operator, which conveys mobile originated access requests and traffic. 

: s 

5 When the MS 100 moves from a cell served by a first BTS 50 to a cell served by another BTS 

I 15 50, when both are controlled by the same BSC 40, an inter-BSC handover (HO) is executed, 

f However, the MS 1 00 may also transition between cells served by BTSs 50 that are individually 

Q controlled by different BSCs 40. In this case the HO is considered to be an intra-BSC HO. 

I The air interface standard can conform to any suitable standard or protocol, and may enable both 
m 20 voice and data traffic, such as data traffic enabling Internet 70 access and web page downloads. 

In the presently preferred embodiment of this invention the air interface standard is a Time 
Division Multiple Access (TDMA) air interface that supports a GSM or an advanced GSM 
protocol and air interface, although these teachings are not intended to be limited to TDMA or 
to GSM or GSM-related wireless systems. 

25 

The network operator may also include a suitable type of Message Center (MC) 60 that receives 
and forwards messages for the mobile stations 100. Other types of messaging service may 
include Supplementary Data Services and one under currently development and known as 
Multimedia Messaging Service (MMS), wherein image messages, video messages, audio 
30 messages, text messages, executables and the like, and combinations thereof, can be transferred 
between the network and the mobile station 100. 
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The mobile station 100 typically includes a microcontrol unit (MCU) 120 having an output 
coupled to an input of a display 140 and an input coupled to an output of a keyboard or keypad 
160. The mobile station 100 may be a handheld radiotelephone, such as a cellular telephone or 
a personal communicator. The mobile station 100 could also be contained within a card or 
5 module that is connected during use to another device. For example, the mobile station 1 0 could 
be contained within a PCMCIA or similar type of card or module that is installed during use 
within a portable data processor, such as a laptop or notebook computer, or even a computer that 
is wearable by the user. 

10 The MCU 120 is assumed to include or be coupled to some type of a memory 130, including a 
read-only memory (ROM) for storing an operating program, as well as a random access memory 
(RAM) for temporarily storing required data, scratchpad memory, received packet data, packet 
data to be transmitted, and the like. A separate, removable SIM (not shown) can be provided as 
well, the SIM storing, for example, a preferred Public Land Mobile Network (PLMN) list and 
2 15 other subscriber-related information. The ROM is assumed, for the purposes of this invention, 
H to store a program enabling the MCU 120 to execute the software routines, layers and protocols 
l_ required to implement the improved MS LCS procedure n accordance with these teachings, as 
H well as to provide a suitable user interface (UI), via display 140 and keypad 160, with a user, 
h" Although not shown, a microphone and speaker are typically provided for enabling the user to 
20 conduct voice calls in a conventional maimer. 



Is! 
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The mobile station 100 also contains a wireless section that includes a digital signal processor 
(DSP) 180, or equivalent high speed processor or logic, as well as a wireless transceiver that 
includes a transmitter 200 and a receiver 220, both of which are coupled to an antenna 240 for 
25 communication with the network operator. At least one local oscillator (LO) 260, such as a 
frequency synthesizer, is provided for Uining the transceiver. Data, such as digitized voice and 
packet data, is transmitted and received through the antenna 240. 

It has been realized that the termination of the positioning procedure is in most cases 
30 unnecessary, but may be required, as the MS 100 is expected to behave in the same manner for 
both intra-BSC and inter-BSC HOs, i.e., the MS 100 does not typically know a priori when the 
BSC 40 will be changed during the HO procedure. In all cases in the following Table the 
positioning procedure is terminated according to current specifications. In ttie Table are also 
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listed what kind of effects the HO or other RR procedure has on the LCS, and what is required 
to be done in order to continue the LCS procedure. 



5 



Positioning method 


RR Procedure 


Effect on positioning 
measurement process 


Actions required to 
continue positioning 
procedure 




Inter MSC/SGSN 




New serving BSC/SMLC 




handover/CRS 




and MSC/SGSN needs to be 
informed about the ongoing 
positioning procedure and its 
parameters (or the MS's 
response should be send to 
previous SMLC and 
MSC/SGSN). 




Inter BSC 


None*# 


New serving BSC/SMLC 


(Assisted) GPS 


nanQOver/ v^ivo ^iiiua 
MSC or SGSN'i 




needs to be informed about 
the ongoing positioning 
procedure and its parameters 
(or the MS's response should 
be send to old SMLC). 




Intra BSC 




Nothing 




handover/CRS 








Other RR management 


None 


Nothing 




procedure (=Intra Cell 








procedure) 
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Inter MSC/SGSN 


Assistance data 


New serving BSC/SMLC 




handover/CRS 


delivered to MS is not 
valid anymore. But 
there is possibility that 
the MS has already 
managed to make the 
majority of the 


and MSC/SGSN needs to be 
informed about the ongoing 
positioning procedure and its 
parameters (or the MS's 
response should be send to 
old SMLC and MSC/SGSN). 


E-OTD 


Inter BSC 

handover/CRS (Intra 
MSC or SGSN) 


measurements, or MS 
can internally convert 
the assistance data to 
new serving BTS, and 
the amount of new 
neighbor BTSs is small, 
in these cases it would 


New serving BSC/SMLC 
needs to be informed about 
the ongoing positioning 
procedure and its parameters 
(or the MS's response should 
be send to the previous 
SMLC). 




Intra BSC 


be still possible to 
continue the 


Nothing 




handover/CRS 


measurement procedure 
m Mo unaer ine new 
serving x> i o. rr 






Other RR management 


None 


Nothing 




procedure (=Intra Cell 








procedure) 







♦Note: this assumes that either GSM to GPS time relation is not included to the assistance data, 
or the MS manages to utilize the GSM to GPS time relation in the previous cell before the 
5 occurrence of the HO. 

#Note: The standard should allow the MS to send either the measurement response (with valid 
measurement data), or an error indication (in case the MS cannot perform satisfactory 
measurements under the new serving BTSs). 



10 In order to avoid termination of an ongoing LCS procedure due to an occurrence of some RR 
procedure (e.g. HO or CRS), the LCS process (with the required parameters) is preferably 
continued from thecurrentservingBSC/RNC/SMLCandMSC(server)/SGSN to thenew serving 

entities with a relocation procedure. It is noted that for the case of intra-BSC procedures this is 



11 

not required, but the termination of the LCS procedure was not avoidable in R98 and R99 as the 
MS 100 was required to behave in some predictable manner irrespective of whether there is an 
inter-BSC/CRS or intra-BSC handover/CRS. 

It is preferred that the positioning procedure never be terminated in the case of HO, CRS or some 
5 other RR procedure, if the measurement command has been delivered successfully to the MS 
100. If the HO or CRS should occur during the transfer of a measurement command (or 
assistance data) to the MS 100 the positioning procedure may be terminated, or it may be 
continued, possibly at the choice of the network operator. 

10 Relocation Procedure with LCS Data 

Fig. 4 provides an example of the relocation procedure with LCS data for the case of the Cell 
Reselection (PS domain) in accordance with an aspect of this invention. Fig. 4 maybe contrasted 
with the conventional procedure depicted in Fig. 3. In Fig. 4, the MS 100 can be seen to perform 
a cell update in the new cell first, and after that to send a response to the GPS/E-OTD 

15 measurement command (see Step 12X). Other improvements and modifications to the 
conventional Cell Reselection (PS domain) procedure are made apparent in the ensuing 
description of Fig. 4. Note should be made, however, that these teachings are not limited for use 
only with the illustrated Combined CellAJRA/GRA Update and SRNS Relocation procedure for 
the PS domain procedure, but can be applied as well, by example, to the Combined Hard 

20 Handover and SRNS Relocation procedure for the PS domain shown in Fig. 2, and also to the 
Combined Hard Handover and SRNS Relocation procedure for the CS domain. These teachings 
apply as well to LCS Reselection in an IP RAN architecture, as will be discussed below. 

Referring now to the enumerated process steps shown in Fig. 4, a description of each step is now 
25 provided. 

1) After having made cell re-selection, the MS 100 sends a Cell Update/URA/GRA Update 
message to the UTRAN or, in accordance with an aspect of these teachings, to the GERAN. 
Upon reception of the message, the target RNC/BSC forwards the received message towards the 
30 source SRNC via lur (note that in the following signal flow description a reference to RNC 
denotes as well the BSC for the GERAN case). The source SRNC then decides to perform a 
Combined CellAJRA/GRA Update and SRNS Relocation towards the target RNC. 
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2) The source SRNC initiates the relocation preparation procedure by sending a Relocation 
Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to Target RNC 
Transparent Container) to the old (previous) SGSN. The source SRNC sets the Relocation Type 
to "UE not involved". The Source RNC to Target RNC Transparent Container includes the 
5 necessary information for Relocation co-ordination, security functionality, and RRC protocol 
context information (including UE Capabilities). 

In accordance with an aspect of this invention, the LCS parameters (e.g., requested LCS QoS, 
what positioning procedure is active, details of the currently ongoing location process, GMLC 
10 Address of the active positioning procedure) may be included in the Relocation Required 
message in the Source RNC to Target RNC Transparent Container. Note in this regard that the 

M> LCS QoS includes, for example, the required location accuracy and the response time. Another, 

Q less preferred technique is described below with respect to Step 7. 

3) The old SGSN determines from the Target ID if the SRNS Relocation is an intra-SGSN SRNS 
relocation or an inter-SGSN SRNS relocation. In case of inter-SGSN SRNS relocation the old 
SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation 
Request (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context, Target 
Identification, UTRAN Transparent Container, RANAP Cause) message to the new SGSN. At 
the same time a timer is started on the MM and PDP contexts in the old SGSN, as specified in 
the Routeing Area Update procedure in the subclause Location Management Procedures (UMTS 
Only) found in 3G TS 23.060. The Forward Relocation Request message is applicable only in 
the case of the inter-SGSN SRNS relocation. 

25 4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, 
CN Domain Indicator, Source RNC to Target RNC Transparent Container, RABs To Be Setup) 
to the target RNC. For each RAB requested to be established, RABs To Be Setup contain 
information such as RAB ID, RAB parameters. Transport Layer Address and lu Transport 
Association. The RAB ID information element contains the NSAPI value, and the RAB 
30 parameters information element gives the QoS profile. The Transport Layer Address is the 
SGSN Address for user data, and the lu Transport Association corresponds to Tunnel Endpoint 
Identifier Data. 
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After all necessary resources for accepted RABs, including the lu user plane, are successfully 
allocated, the target RNC sends the Relocation Request Acknowledge (RABs setup, RABs 
failed to setup) message to the new SGSN. The target RNC, for each RAB to be setup (defined 
by an IP Address and a Tunnel Endpoint Identifier), receives both forwarded downstream PDUs 
5 fi-om the source SRNC as well as downstream PDUs from the new SGSN. 



5)When resources for the transmission of user data between the target RNC and the new SGSN 
have been allocated, and the new SGSN is ready for relocation of SRNS, the Forward Relocation 
Response message (Cause, RANAP Cause, and Target RNC Information) is sent fi-om new 

10 SGSN to old SGSN. This message indicates that the target RNC is ready to receive from the 
source SRNC the downstream packets not yet acknowledged by the MS 100, i.e., the relocation 
resource allocation procedure is terminated successfiilly. RANAP Cause is information fixjm the 
target RNC to be forwarded to the source RNC. The RAB Setup hiformation, one information 
element for each RAB, contains the RNC Tunnel Endpoint Identifier and RNC IP address for 

1 5 data forwarding from the source SRNC to target RNC. If the target RNC or the new SGSN failed 
to allocate resources the RAB Setup Information element contains only the NSAPI indicating 
that the source RNC is to release the resources associated with the NSAPI. The Forward 
Relocation Response message is applicable only in the case of inter-SGSN SRNS relocation. 

20 6) The old SGSN continues the relocation of SRNS by sending a Relocation Command (RABs 
to be released, and RABs subject to data forwarding) message to the source SRNC. The old 
SGSN determines the RABs subject to data forwarding based on QoS, and those RABs are 
contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the 
information element is specified to contain the RAB ID, Transport Layer Address and lu 

25 Transport Association. The Transport Layer Address and lu Transport Association is used for 
forwarding of DL N-PDU from the source RNC to the target RNC. 

7) Upon reception of the Relocation Conunand message from the PS domain, the source RNC 
starts a data-forwarding timer. When the relocation preparation procedure is terminated 
30 successfiilly, and when the source SRNC is ready, the source SRNC triggers the execution of 
relocation of SRNS by sending a Relocation Commit (SRNS Contexts) message to the target 
RNC. The purpose of this procedure is to transfer SRNS contexts from the source RNC to the 
target RNC. SRNS contexts are sent for each concerned RAB and contain the sequence numbers 
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of the GTP-PDUs next to be transmitted in the uplink and downlink directions, and the next 
PDCP sequence numbers that would have been used to send and receive data from the MS 100. 
For connections using the RLC unacknowledged mode the PDCP sequence number is not used. 

5 In accordance with these teachings, and as was discussed above in Step 2, the LCS parameters 
may be included in the Relocation Conmiit message, although this technique is not presently 
more preferred than including the LCS parameters in the Relocation Required message in the 
Source RNC to Target RNC Transparent Container. 

10 8) After having sent the Relocation Commit message, the source SRNC begins the forwarding 
of data for the RABs subject to data forwarding. The data forwarding at SRNS relocation is 
carried out through the lu interface, meaning that the data exchanged between the source SRNC 
and the target RNC are dupUcated in the source SRNC and are routed at the IP layer towards the 
target RNC. 

15 

9) The target RNC sends a Relocation Detect message to the new SGSN when the relocation 
execution trigger is received. For the SRNS relocation type UE Not Involved, the relocation 
execution trigger is the reception of the Relocation Commit message from the lur interface. 
When the Relocation Detect message is sent, the target RNC starts SRNC operation. 

20 

10) After having sent the Relocation Detect message, the target SRNC responds to the MS 100 
by sending a Cell Update Confirm/URAyORA Update Confirm message. Both messages contain 
UE information elements and CN information elements. The UE information elements include 
among other information the new SRNC identity and S-RNTI. The CN information elements 

25 contain among other information the Location Area Identification and Routing Area 
Identification. This procedure is co-ordinated in all lu signalling connections existing for the MS. 

1 1) Upon reception of the Relocation Detect message, the CN may switch the user plane from 
the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation, 

30 the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN 
Tunnel Endpoint Identifier, QoS Negotiated) to the GGSNs concerned. The GGSNs update their 
PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint 
Identifier) message. 
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12) When the MS 1 00 has reconfigured itself, it sends the RNTI Reallocation Complete message 
to the target SRNC. 

12X) In accordance with these teachings, if some positioning procedure was ongoing in the MS 
5 100, the MS 100 sends the response message including successful measurement reports or a 
failure indication. The message may be sent before of after sending the RNTI Reallocation 
Complete message. In this manner the ongoing MS 100 positioning procedure is not required to 
be terminated, thereby overcoming the problems that were discussed above. The measurement 
results message may be sent by the mobile station before or after sending a GERAN/UTRAN 
10 Mobility Information Confirm message from the mobile station to the target BSC/RNC. 

H 13) When the target SRNC receives the RNTI Reallocation Complete message, i.e., the new 
S SRNC-ID + S-RNTI are successfully exchanged with the UE by the radio protocols, the target 
1 SRNC initiates the Relocation Complete procedure by sending the Relocation Complete message 
S 15 to the new SGSN. The purpose of the Relocation Complete procedure is to indicate by the target 
S SRNC the completion of the relocation of the SRNS to the CN. If the user plane has not been 
switched at Relocation Detect, the CN upon reception of Relocation Complete switches the user 
plane from the source RNC to the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS 
relocation, the new SGSN signals to the old SGSN the completion of the SRNS relocation 

■-sra 

b 20 procedure by sending a Forward Relocation Complete message. 



lU 



1 4) Upon receiving the Relocation Complete message, or if it is an inter-SGSN SRNS relocation; 
the Forward Relocation Complete message, the old SGSN sends an lu Release Command 
message to the source RNC. When the RNC data-forwarding timer started in Step 7 expires the 

25 source RNC responds with an lu Release Complete. 

1 5) After the MS 1 00 has finished the CellAJRA/GRA update and RNTI reallocation procedure, 
and if the new Routing Area Identification is different from the old, the MS 100 initiates the 
Routing Area Update procedure. See in the regard the subclause Location Management 

30 Procedures (UMTS Only). Note that it is only a subset of the RA update procedure that is 
performed, since the MS 1 00 is in the PMM-CONNECTED state. 
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LCS Relocation in IP R AN Architecture 



A discussion is now made of the positioning signaling flow in a particular IP RAN architecture. 
Reference can also be made to Fig. 5 for a discussion of the positioning signaling flow. 

5 

It should be noted, however, that this procedure need not be IP RAN specific, and could be 
employed as a normal positioning procedure in UTRAN (or GERAN) by replacing references 
to Radio Network Access Server (RNAS) with RNC. It should be noted that the RNAS 
functionality can be integrated into the BTS functionality. 

10 

1) The SGSN/MSC server sends a Location Request to the RNAS. 

2) The RNAS knows in which cell the MS 100 is located, or pages the MS 100 to determine the 
current cell where the MS 100 is located. If the Location Request only requires the service area 

15 id the RNAS may send this directly to the SGSN/MSC server without involving the SMLC. 

3) The RNAS sends a Location Request to the SMLC. The SMLC determines if the cell accuracy 
(with possible other available information, such as the current Timing Advance value and the 
received signal level) is sufficient, and then translates the cell id (and possibly the other avaiable 

20 information) into MS 100 location coordinates. If better accuracy is required, the SMLC requests 
the RNAS to obtain measurement results of the target MS 100. 



4) The RNAS sends a measurement request to the target MS 100. 
25 5) The target MS 100 sends the measurement results to the RNAS. 

6) The RNAS sends the measurement results to SMLC. 

7) The SMLC requests measurement results from the LMU (or the LMU reports periodically 
30 the SMLC, in which case this step and the next step (8) can be omitted). 

8) The LMU sends the measurement results to the SMLC 
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9) The SMLC calculates the location of the target MS 100. 



10) The SMLC sends the location calculation results to the RNAS. 

5 1 1) The RNAS sends the location result to the SGSN/MSC server. 

The IP RAN Architecture has some effect on the LCS relocation procedure in the HO/CRS case. 
In the IP RAN architecture the SMLC and possibly the RNAS may be maintained the same 
during the positioning procedure regardless of the HO or CRS (i.e., the occurrence of the HO or 

10 CRS does not require a change in the RNAS or the SMLC). This means that in the IP RAN 
architecture the relocation procedure with the transfer of the LCS parameters is not required, if 
the RNAS is not changed. In the case where the RNAS is changed, the SMLC would still be the 
same, and in this case the new RNAS is required to find the SMLC. This can be accomplished 
if during the relocation procedure the address of the SMLC is transported from the old RNAS 

15 to the new RNAS. 

It should be noted that absent the use of this invention the MS 100 will always abort the 
positioning procedure in the case of HO or CRS. This appUes as well to the IP RAN architecture 
discussed above. 

20 

It should be appreciated that the improved LCS procedure in accordance with these teachings 
does not prematurely terminate as often as in the prior art due to an occurrence of some HO, 
CRS, or other RR procedure, and thereby provides reduced average delays, lower power 
consumption in the MS 100, and improved service to the end user. 

25 

While described in the context of presently preferred and exemplary embodiments of these 
teachings, those skilled in the art will recognize that changes in form and details may be made, 
and that these changes will still fall within the scope of these teachings. 



